Bandwidth control by logicog · Pull Request #147 · logicog/RTLPlayground

logicog · 2026-03-02T06:44:41Z

Add a bandwidth control mechanism for ingress and egress at a given port.

The documentation contains an example making use of this feature using loopback on a Linux device through an external RTL-switch. Applications of the feature include configuring bandwidth shares of e.g. an uplink connection and the simulation of low bandwidth connections with or without packet drops.

feelfree69 · 2026-03-02T09:00:39Z

rtl837x_bandwidth.c

+	sfr_data[3] = (*(bwptr) >> 4) | (*(bwptr + 1) << 4);
+	reg_write_m(RTL837X_IGBW_PORT_CTRL + port * 4);
+
+	// We enable Flow Control instead of just dropping packets


I would make this as a configuration option. Usually, enabling Flow Control is a bad idea.

It is configurable, you can change it to dropping the packets instead via bandwidth_ingress_drop(). While indeed FC is not great and depends on the support by the linkpartner, it is much better than the alternative, namely to drop the packets, see the examples in the documentation: bandwidth.md. As can be seen, the traffic is no longer deterministic because of packets being dropped arbitrarily in the middle of the configuration causing TCP back-off to trigger. Using Flow Control, the data stream shows reliably the desired bitrate without any dropped packets. So I prefer making FC the default in order to not surprise the user with bitrates that are erratic.

feelfree69 · 2026-03-02T11:06:29Z

doc/bandwidth.md

+
+To drop packets when the bandwidth is exceeeded at port 2 do:
+```
+> bw in 2 drop 


What is the way back, i.e. to enable FLowControl again?

This is maybe a misunderstanding. The bandwidth control does not enable or disable FlowControl. FC is a PHY feature, here we are talking about scheduling even before the MAC layer. The bandwidth control merely uses FC or not. It is not enabling or disabling it. This would require to configure the PHY. I verified it using sudo ip netns exec client ethtool -a : if you disable the use of FC, it still is configured and enabled on the link, even if no longer used. It is even used during transmission, it is just not used when the bandwidth is exceeded to lower throughput.

So drop explicitly stops usage of FC. To enable it again, one can again use bw in 1 1000.

Do you want an explicit command/function to enabled/disable use of FC?

Do you want an explicit command/function to enabled/disable use of FC?

Yes, see my comment on bandwidth_ingress_set. There you implicitly switch FC on
And you have a command to switch FC off (ie to drop packets), but no command to switch FC back on, other than setting the bandwidth limit again.
While the config in SoC in regards of ingress bandwidth and FC is perfectly separated, the console commands are not. That looks as a bad design to me.

feelfree69 · 2026-03-02T11:09:22Z

doc/bandwidth.md

+To enable bandwidth control of ingress for physical port 2 to be set to 256 Kbit/s
+do:
+```
+> bw in 2 0100 


This implictly enables flow control, which does work only if the link partner enables it too at its RX side.

I would make the FlowControl feature configurable explicitly.

No, this is a misunderstanding, see above. FC is neither enabled nor disabled. This would not be possible at this level. FC stays on all the time even if not used. BTW: by default it is enabled and used if the link partner enables it. There is no way currently to configure it at the link level. The idea is that like EEE if it works it is good, if not, there is nothing much you can do. So we keep the default for all involved PHYs, which enables it by default.

feelfree69 · 2026-03-02T11:32:20Z

doc/bandwidth.md

+  Configures or shows the status of bandwidth control
+```
+The bandwidth is given as the `<hexvalue>` in Kbit/s. Note that the control is only
+possible at a granularity of 16 Kbit/s and the minimum value is also 16 Kbit/s. The


I think it's ok at the console to have this granularity of what the chip supports and the unintuitive way of using hex values.
When adding this feature to the Web-Interface, I would expect eg a list of dedicated values, eg. from 16 kbit/s to 10 Gbit/s in steps of factor 2 or 4.

Good idea! In the web-interface configuring and verifying the settings is much easier. I have already a skeleton for the web-page but wanted the basics to be done, first.

logicog · 2026-03-03T05:23:07Z

I added the possibility to revert to flow control for bandwidth management via bw in <port> fc. Also the drop option had been somehow dropped from the previous commit to the PR, so that code has been restored.

feelfree69 · 2026-03-02T14:35:21Z

doc/bandwidth.md

+
+To drop packets when the bandwidth is exceeeded at port 2 do:
+```
+> bw in 2 drop 


Do you want an explicit command/function to enabled/disable use of FC?

Yes, see my comment on bandwidth_ingress_set. There you implicitly switch FC on
And you have a command to switch FC off (ie to drop packets), but no command to switch FC back on, other than setting the bandwidth limit again.
While the config in SoC in regards of ingress bandwidth and FC is perfectly separated, the console commands are not. That looks as a bad design to me.

logicog · 2026-03-03T20:30:47Z

I added the FC re-enable command and function and rebased.

cmd_parser.c

vDorst

Not all bw commands are working.

cmd_parser.c

logicog · 2026-03-05T06:43:57Z

I fixed all of the above and re-based to latest main.

vDorst · 2026-03-06T20:31:36Z

cmd_parser.c

+
+	port = machine.phys_to_log_port[port];
+
+	if (cmd_words_b[1] > 0 && cmd_compare(1, "status")) {


Because we change (cmd_words_b[3] < 0) on L706.
Then cmd_words_b[1] > 0 is always true?
So need we still need to check this?

Same as below (cmd_words_b[3] > 0) is that also always true?

logicog · 2026-03-07T05:44:20Z

I fixed the issue with the redundant checking of the number of present arguments in the command. The logic is now: check for 2 arguments for the status command, then require 3 arguments for all the other commands and no more checking for argument presence in any of the further command argument comparisons.

vDorst · 2026-03-08T17:47:41Z

I finally setup everything so I can test it for real.

tested SFP to SFP @ 10Gbit.

value 800000 result into

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  5.93 GBytes  5.09 Gbits/sec  49540            sender
[  5]   0.00-10.00  sec  5.93 GBytes  5.09 Gbits/sec                  receiver

value 10000000 seems not working

> bw in 6 10000000
bandwidth_ingress_set called, port 03

> bw status 6
ingress: enabled: 0x00000000
egress: disabled

Setup value 800000 shows 80000 in the status.
That seems strange.

> bw in 6 800000
bandwidth_ingress_set called, port 03

> bw status 6
ingress: enabled: 0x00080000
egress: disabled

logicog · 2026-03-08T17:59:49Z

Setup value 800000 shows 80000 in the status. That seems strange.

I think there is a bug, it should be one 0 more. The register content is in units 16KByte. I forgot to shift it correctly. But maybe I just append a 0.

logicog · 2026-03-08T18:08:24Z

Can you try again?

vDorst · 2026-03-08T18:24:55Z

> bw in 6 800000
bandwidth_ingress_set called, port 03

> bw status 6
ingress: enabled: 0x0800000
egress: disabled

with the setting set as above
iperf results

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  6.17 GBytes  5.30 Gbits/sec  56097            sender
[  5]   0.00-10.00  sec  6.17 GBytes  5.30 Gbits/sec                  receiver

is the value correct?
0x800000 = 3032400
3032400 x 16 Kbit/s = 40518400 Kbit/s = 47381 MBit = 47 Gbit.
So that seems off by around 10x.

logicog · 2026-03-08T18:46:07Z

0x800000 is in kbit now. That would be 8.3 Gbit.

…

On 8 March 2026 19:25:16 CET, "René van Dorst" ***@***.***> wrote: vDorst left a comment (logicog/RTLPlayground#147) ``` > bw in 6 800000 bandwidth_ingress_set called, port 03 > bw status 6 ingress: enabled: 0x0800000 egress: disabled ``` with the setting set as above iperf results ``` [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 6.17 GBytes 5.30 Gbits/sec 56097 sender [ 5] 0.00-10.00 sec 6.17 GBytes 5.30 Gbits/sec receiver ``` is the value correct? 0x800000 = 3032400 3032400 x 16 Kbit/s = 40518400 Kbit/s = 47381 MBit = 47 Gbit. So that seems off by around 10x. -- Reply to this email directly or view it on GitHub: #147 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

logicog · 2026-03-08T18:57:50Z

You are using 10 Gbit modules, so there is no flow control. That works only with Ethernet. Lack of FC will account for a 15 to 20% loss in performance when you start throttling.

…

On 8 March 2026 19:25:16 CET, "René van Dorst" ***@***.***> wrote: vDorst left a comment (logicog/RTLPlayground#147) ``` > bw in 6 800000 bandwidth_ingress_set called, port 03 > bw status 6 ingress: enabled: 0x0800000 egress: disabled ``` with the setting set as above iperf results ``` [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 6.17 GBytes 5.30 Gbits/sec 56097 sender [ 5] 0.00-10.00 sec 6.17 GBytes 5.30 Gbits/sec receiver ``` is the value correct? 0x800000 = 3032400 3032400 x 16 Kbit/s = 40518400 Kbit/s = 47381 MBit = 47 Gbit. So that seems off by around 10x. -- Reply to this email directly or view it on GitHub: #147 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

vDorst · 2026-03-08T19:47:30Z

ah that explains it.
Thanks for the work!

logicog requested review from feelfree69 and vDorst March 2, 2026 06:44

feelfree69 reviewed Mar 2, 2026

View reviewed changes

logicog force-pushed the bandwidth branch from e975f2e to a66abc6 Compare March 3, 2026 05:21

feelfree69 approved these changes Mar 3, 2026

View reviewed changes

logicog mentioned this pull request Mar 4, 2026

Bandwidth web #150

Merged

vDorst reviewed Mar 4, 2026

View reviewed changes

cmd_parser.c Outdated Show resolved Hide resolved

vDorst requested changes Mar 4, 2026

View reviewed changes

cmd_parser.c Outdated Show resolved Hide resolved

cmd_parser.c Show resolved Hide resolved

logicog force-pushed the bandwidth branch from a66abc6 to 62ad42e Compare March 5, 2026 06:42

Add iniital implementation of bandwidth control

eb13d4a

logicog force-pushed the bandwidth branch from 62ad42e to 20e6002 Compare March 5, 2026 06:43

vDorst reviewed Mar 6, 2026

View reviewed changes

logicog force-pushed the bandwidth branch from 20e6002 to 23273de Compare March 7, 2026 05:40

logicog requested a review from vDorst March 7, 2026 05:42

logicog added 2 commits March 8, 2026 19:04

Add Bandwidth control for ingress/egreess at port

1836c7d

Add documentation for bandwidth control

04ab083

logicog force-pushed the bandwidth branch from 23273de to 04ab083 Compare March 8, 2026 18:07

vDorst merged commit 87c161d into main Mar 8, 2026
1 check passed


		port = machine.phys_to_log_port[port];

		if (cmd_words_b[1] > 0 && cmd_compare(1, "status")) {

Conversation

logicog commented Mar 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

logicog commented Mar 3, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

logicog commented Mar 3, 2026

Uh oh!

Uh oh!

vDorst left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

logicog commented Mar 5, 2026

Uh oh!

vDorst Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

logicog commented Mar 7, 2026

Uh oh!

vDorst commented Mar 8, 2026

Uh oh!

logicog commented Mar 8, 2026

Uh oh!

logicog commented Mar 8, 2026

Uh oh!

vDorst commented Mar 8, 2026

Uh oh!

logicog commented Mar 8, 2026 via email

Uh oh!

logicog commented Mar 8, 2026 via email

Uh oh!

Uh oh!

vDorst commented Mar 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

vDorst Mar 6, 2026 •

edited

Loading